Conversational bot interaction with utterance ranking

ABSTRACT

A conversational bot system uses a set of conversations that have been annotated to identify speech acts, wherein a speech act is a labeled grouping of utterances. To facilitate processing, a data model associated with a multi-turn conversation is received. The data model comprises an observation history. Upon receipt of query that includes a sequence of at least two or more utterances, an utterance ranking algorithm is applied. The algorithm selectively reorders the utterances in the sequence into a ranked order of importance that reflects a lowest to highest priority of response. In response to applying the utterance ranking algorithm, the data model is then updated to reflect the ranked order. In one embodiment, updating the data model positions the highest priority utterance as a most recent utterance in the observation history. The updated data model is then used to attempt to generate a coherent response to the query.

BACKGROUND Technical Field

This application relates generally to information retrieval methods andsystems.

Background of the Related Art

Online conversational marketing is a well-known technique designed tomove buyers or prospects through marketing and sales funnels through thepower of real-time conversations. In this approach, and instead offorcing users to go through lead capture forms and wait days for aresponse, conversational marketing uses targeted messaging, live chatand intelligent conversational bots (chatbots) to engage with users inreal-time when they visit a website. A chatbot is a software applicationthat executes on the site and that is used to interact with the user,often in lieu of a direct human interaction. Typically, conversationalbots are of several types. A rules-based chatbot follows pre-designedrules that form a decision tree. A more sophisticated approach is anArtificial Intelligence (AI)-based chatbot. An AI chatbot can understandlanguage outside of a closed set of pre-programmed recognized inputs,and it has the capability to learn based on the inputs it receives. Itcan also make changes based on patterns, and it can become smarter overtime as new situations are experienced. This type of chatbot can beapplied to a range of uses, e.g., providing alternatives to humanrepresentatives, sentiment analysis, making predictions about what avisitor is looking for on a website, learning and adapting to userpreferences, and others.

Although AI-based chatbot solutions provide significant advantages,certain common use cases present significant challenges. For example,when a customer says more than one statement at once to theconversational bot, one typical default operation is that the systemresponds to the most recent utterance for which a response action can bedetermined. Depending on context, however, this default behaviorsometimes is not correct, in which case the bot typically produces awrong (or context-inappropriate) response.

There remains a need to provide enhancements to conversational botsystems that enable coherent processing of utterance sequences if andwhen they occur during a conversation.

BRIEF SUMMARY

A method and computing platform provides query understanding to select aresponse in a multi-turn conversation between a user and aconversational bot, where the query comprises a sequence of utterances.As used herein, the notion of a sequence refers to a scenario in whichthe human user interacting with the bot makes two or more utterancesbefore the bot is able to provide a response. According to thisdisclosure, an utterance ranking is applied to the utterances in thesequence to enable the bot to provide a coherent and context-appropriateresponse.

To this end, and in a representative implementation, the conversationalbot system uses a set of conversations that have been annotated toidentify speech acts, wherein a speech act is a labeled grouping ofutterances. To facilitate processing, a data model associated with amulti-turn conversation is received. The data model comprises anobservation history. Upon receipt of query that includes a sequence ofat least two or more utterances, an utterance ranking algorithm isapplied. The algorithm selectively reorders the utterances in thesequence into a ranked order of importance that reflects a lowest tohighest priority of response. In response to applying the utteranceranking algorithm, the data model is then updated to reflect the rankedorder. In one embodiment, updating the data model positions the highestpriority utterance as a most recent utterance in the observationhistory. The updated data model is then used to attempt to generate acoherent response to the query.

The foregoing has outlined some of the more pertinent features of thesubject matter. These features should be construed to be merelyillustrative. Many other beneficial results can be attained by applyingthe disclosed subject matter in a different manner or by modifying thesubject matter as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the subject matter and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram depicting an information retrieval system inwhich the technique of this disclosure may be implemented;

FIG. 2 is a block diagram of a relational database comprising a set ofinter-related data tables in which a corpus of annotated conversationtranscripts is organized to provide storage-efficient informationalretrieval according to one aspect of this disclosure;

FIG. 3 depicts a representative data model that is persisted in adatabase and represents a conversational history for a particularuser-chatbot conversation or session over one-to-many turns;

FIG. 4 depicts a representative system interaction showing processing ofa user query according to an embodiment of this disclosure;

FIG. 5 depicts a first example of a sequence of utterances provided to abot during a conversation;

FIG. 6 depicts a second example of a sequence of utterances provided tothe bot;

FIG. 7 depicts a process flow of a routine to detect a sequence ofutterances that will then be processed to identify which utteranceshould be processed by the bot; and

FIG. 8 depicts a process flow of an utterance ranking algorithmaccording to this disclosure;

FIG. 9 depicts a process flow of how the rankings identified by theutterance ranking algorithm are then applied by the AI-based bot;

FIG. 10 depicts a first example scenario (multiple statements) showingthe operation of the ranking algorithm;

FIG. 11 depicts a second example scenario (mixture of questions andstatement) showing the operation of the ranking algorithm; and

FIG. 12 depicts a third example scenario (multiple questions) showingthe operation of the ranking algorithm.

DETAILED DESCRIPTION

The following is a glossary of terms that are used herein:

Event: a sequence of observations, recognizable as a coherent behavior.Observations within the sequence can be an arbitrary mix of speech actsand physical acts, from multiple actors. One event can be represented bymany different possible expressions of that event.

Event expression: one specific sequence of one or more observations thatcan represent some event. An event may unfold in many different ways,i.e., there may be many different sequences of saying things, and takingphysical actions.

Event recognition: inferring which event is unfolding, or has unfolded,by comparing a sequence of observations to sequences that compose theexpressions for some event.

Event aliasing: inferring which event is unfolding, or has unfolded,with an inexact match. When an exact sequence is not recognized, aclosest inexact match can be determined and presented as an alias suchthat further processing can then be performed as if the closest inexactmatch was recognized as a known sequence.

Observation: an atomic action taken by an actor. Each action may be aphysical act or a speech act. One or more observations may beintermingled between or among events as the events unfold in parallel,in which case the events themselves are active (in time) concurrently.Each observation is a member of one event, but as noted events canoverlap in time, e.g., given observations 1-4, observations 1 and 3 maybe part of event 1, while observations 2 and 4 may be part of event 2,such that events 1 and 2 are both active over a time period. As thisexample shows, observations from different events may be arbitrarilysequenced among observations from other events.

Physical act: a non-linguistic action taken by an actor, e.g., clickinga button or a link on a Graphical User Interface (GUI), entering data ina form, or the like. A physical act also may be received via moresophisticated data entry mechanisms, such as a gesture-based interfacethat reads and interprets facial expressions, biometric devices thatreceive and interpret physical features or movements, etc.

Speech act: an utterance expressed by one actor to another, in naturallanguage. A speech act has some purpose for expressing it, and typicallyit can be expressed in many different ways to accomplish the same thing.The utterance may be typed text (e.g., in a chat window), transcribedfrom spoken audio, or the like.

Utterance: a sequence of words that is grammatically complete; usuallyone sentence.

Multi-turn conversation: typically, an interaction between end userparticipating in a chat, and a conversational hot, typically overmultiple question and answer cycles. A multi-turn conversation mayinvolve more than one human user, and more than one bot. For example, abot may be configured to talk to multiple users concurrently (e.g.,participants in a Zoom® web conference).

FIG. 1 depicts a representative information retrieval system in whichthe techniques of this disclosure may be implemented. In one embodiment,and which is not intended to be limiting, a multi-turn conversation iscarried out between an end user 100, and a conversational bot softwareapplication 102 that executes in a network-accessible computing platform104. The end user 100 is a human being that interacts with the platform,typically using a client machine 106 having a browser or mobileapplication (app). In a typical user case, the software application 102executes in association with a website 108, although the chatbotfunctionality may be utilized by multiple distinct websites operated byseparate and independent content providers. As such, the computingplatform provides the chatbot functionality in a multi-tenant operatingenvironment, although this is not a requirement. The user provides inputto the chatbot as speech, as one or more physical actions (e.g.,selecting a button or link, entering data in a field, etc.), or as somecombination of speech and physical action. The chatbot 102 herein is anAI-based conversational bot. As depicted in FIG. 1, preferably theplatform is configured with a network-accessible front end component110, together with an Application Programming Interface (API)-accessibleback-end system 112. The API is depicted at 114. The back-end systemexecutes an instance of the software application 102 for each multi-turnconversation and, in particular, it provides both an understanding of auser's query (a speech and/or physical input), as well as a possibleresponse to this query. Typically, the front-end system handles inputsfrom multiple end users that access the platform, and individualresponses as determined by the back-end system (and in particular thesoftware application instance that is managing the particular multi-turnconversation) are passed from the back-end to the front-end for deliveryto the end user. In the context of a chatbot, the response typically isprovided in a chat window.

Preferably, during a multi-turn conversation between the user and theconversational bot, it is desired that the system responds to a userinput in less than a given time period (e.g., a few seconds) givennetwork latency and transit time, and that such response is both correctand coherent with respect to the history of the conversation so far,i.e., the history of previous utterances or physical actions by theuser. To this end, and according to a first aspect of this disclosure,information against which a query is processed preferably is organizedin a particular manner. This information typically is a corpus ofhistorical conversation transcripts that are first annotated (e.g., byhuman analysts) to provide an information database, e.g., queries andassociated responses, that have been generated by the system previously.The nature and scope of the annotations are implementation-specific, butthe notion is that the database provides a large corpus of possibleconversational flows that the system may then use during a real-timemulti-conversation between the user and the chatbot.

According to this disclosure, and as shown in FIG. 2, preferably theconversational transcripts 200 are annotated and then re-organized intoa set of inter-related data tables that are structured in a specificmanner to enable the system to make fast, discrete comparisons between alive conversation (i.e., a current one) and a corpus of conversions thathave been seen in the past (i.e., the annotated historicalconversations). This re-organization is sometimes referred to herein aspacking. The set of data tables comprises an event bindings table 202,an events table 204, an observations table 206, a physical acts tables208, and a speech acts table 210. The event bindings 202 table stores aset of event bindings, which are entities that connect lines oftranscripts with whatever events these lines have been annotated torepresent in the transcript. The events table 204 stores pointers toevents, wherein an event typically is composed of a linear sequence ofobservations that represent an expression of the event. The observationstable 206 stores pointers to observations that are either physical actsin the physical acts table 208, or speech acts in the speech acts table210. As will be described, information in the relational database issearched in response to physical acts or speech acts, and the lattertypically are organized as clusters of utterances 212. As defined above,an utterance 214 typically is a grammatically-complete set of words,nominally a complete sentence. Thus, and as depicted, the event bindings(event expressions) point to events, which point to the observations,either physical or speech acts. As will be described, this layout of therelational database enables the system to place an utterance or useraction into its appropriate context in a highly-efficient manner,thereby giving the user input meaning within the conversational flow. Inparticular, the tables allow the system to efficiently search for allinstances of an utterance or action (speech or physical act) within theannotated transcripts. Typically, the relational database tables arecontinually updated as the system interacts with end users; in oneembodiment, the data tables are repacked periodically, e.g., every 10-20minutes, although this is not a requirement.

Efficient querying according to the techniques herein is facilitated byrepresenting observations as either speech or physical acts, and whichare taken by either actor (conversation participants), and that arefluidly intermixed to form events. To this end, and according to afurther aspect of this disclosure, as a multi-turn conversationproceeds, the system generates and persists in memory a data model (or,more generally, a data structure) that represents a conversation historybetween the user and the bot. Generally, the data model comprises anobservation history, together with a set of events that have beendetermined to represent the conversation up to at least one turn. FIG. 3depicts an example of one such data model. As depicted, event 302 has aparticular event identifier “787968,” which is an entry in the eventstable. The event has a particular type, in this example “Schedule_Demo.”Based on the conversation so far, the event is composed of a sequence ofobservations (looking left to right) including an observation 302(identifier “765576,” which is an entry in the observations table), andobservation 304 (identifier “4453,” which is another entry in theobservations table). Observation 302 points to a speech act 306(identifier “53709,” which is an entry in the speech acts table), whichspeech act in turn is associated to the conversation participants 308,in this case wherein the “actor” is the bot and the “listener” is theuser. As also indicated, the speech act 306 has been associated to anutterance cluster 310, in this example the “Offer_Demo.” In thisexample, the utterance cluster is common to utterances 312 and 314(e.g., “Would you like to schedule a demo?” or “Would you like to seehow the app works on a website?). Although just two utterances aredepicted for the cluster, there may be any number of utterances. Theentities 302, 306, 308, 310, 312 and 314 thus comprise a hierarchicalrepresentation of a first observation in the sequence of observationsthat comprise the event, and this activity is implemented by thechatbot.

More generally, utterances such as described preferably are used astraining data for a machine learning (ML)-based statistical classifier;upon training, the classifier is then useful for both checking for exactmatches, as well as for further generalization, i.e., finding otherwordings that have a similar meaning to words and phrases recognized bythe classifier.

Referring back to FIG. 3, the second observation 304 represents theuser's response to what in this example is a prompt from the bot Inparticular, the observation 304 is associated with physical act 316having identifier “87302,” which is another entry in the observationsdata table. In this portion of the tree, conversation participants arereversed, such that in entity 318 the “actor” is the user, and the“target” of the physical act is the bot. As also depicted, physical act316 also points to a particular button 320, representing the userresponding that he or she wants to see the demonstration (the “Yes_Demo”action). The data model continues (on the right) with the next follow-onobservation, e.g., an utterance by the user, another physical act, andso forth.

As can be seen then, the data model represents each event as beingcomposed of an observation sequence, which is sometimes referred toherein as an observation history. As the data model is persisted (and inthe depicted tree grows right-ward), the conversation history betweenthe user and the bot is represented. In particular, and at any point inthe multi-turn conversation, the data model comprises the observationhistory, namely, a hierarchical set of events that have been determinedto represent the conversation up to at least one conversation turn (andtypically many turns). More specifically, the data model is theobservation history (everything said, and every button clicked, sincethe beginning of the conversation), and a tree of events that the systemhas overlaid on top of the observations to represent the system's bestguess at explaining how a linear sequence of observations breaks downinto coherent fragments of conversation. Persisting a data model that isbuilt in this manner (and based on both utterances and physical actions)provides significant advantages because real conversations do not alwaysunfold neatly into a linear sequence of topics. Instead, often they aretypically quite messy, fluidly oscillating between several topics.

According to a further aspect of this disclosure, the data model keepstrack of any number of events, all of which can be actively “extended”at any time. As described herein, an event can be extended whenappending an identified observation creates a new sequence ofobservations that exactly matches an existing event expression. Thus, anevent can be extended if appending the most recent observation creates anew (longer) sequence that exactly matches a sequence in the eventstable of the relational database. As noted above, the events tableagainst which the matching is attempted is populated during packing,based on human annotation of events found in real human conversationtranscripts. When appending an observation to an existing eventexpression in the data model is not possible, the system determines ifit can create a new event with the observation then being the initialobservation for the new event sequence. In circumstances when aparticular observation does not fall neatly within an event expression(i.e., it cannot be used extend the event), or when the observation doesnot make sense as a new event, the system then provides a fallback (orfailover) operation to enable processing to continue efficiently. Thisfallback operation is referred to herein as event aliasing.

As defined above, event aliasing refers to the notion of inferring whichevent is unfolding, or has unfolded, with an inexact match. Inparticular, when an exact sequence is not recognized, preferably aclosest inexact match is determined and presented as an alias such thatfurther processing can then be performed as if the closest inexact matchwas recognized as a known sequence. When an aliased event is created,the system then proceeds to process the alias event as the event beingspoofed (and thus no longer sees the inexact match). Aliasing may becarried out either to extend an event (an “aliased extension”), or evento create a new event (“aliasing a new event”). Preferably, and as notedabove, the system first tries to extend an event (using an exact match);then, if extending an event fails, the system then determines if it cancreate a new event (if this can be done logically given the conversationhistory so far). Once the latter option fails, the system fails over toattempt to generate an aliased extension and, failing that, performsaliasing for a new event. Event aliasing is advantageous, as it enablesthe system to provide coherent and appropriate responses even when thedatabase lookup does not return exact (or otherwise useful) results. Themechanism enables the system to pretend it has seen a sequence ofobservations that exactly matches something in the database, when inreality the system observed something very similar but that, e.g. skipsan utterance in the middle, re-orders two utterances within thesequence, or the like. Event aliasing enables to system to operatecoherently even when there is no exact match for a sequence that can beextended with the most recent observation. In this manner, the sequenceis auto-corrected to something that is close enough to what has beenobserved. This approach ensures that the rest of the system functionsefficiently with exact look-ups into tables within the relationaldatabase.

The intelligent packing of the relational database, and the use of thedata model structured as described, enables the system to participate ina multi-turn conversation, coherently, and quickly. The system hasseveral options for flexibly understanding the meaning of an utterance,where aliasing is the fallback, and where meaning is ascribed based onwhich observation is seen at which step of an event, within a sequenceof events that compose a conversation. Events are of arbitrary length,and they can overlap in time with other events. Thus, and although notdepicted in the example event hierarchical representation shown in FIG.3, multiple events may be active concurrently.

In this example depicted in FIG. 3, two different utterances areindicated as being members of an utterance cluster. Preferably, andmentioned above, the system defines utterance clusters by training amachine learning (ML) classifier.

A conversational bot system 400 that implements the techniques of thisdisclosure is shown in FIG. 4. The system is configured to process aquery (e.g., a user utterance or physical act) within a given turn ofthe multi-turn conversation. It assumes that the corpus of annotatedconversation transcripts is packed into a relational database 402comprising the set of inter-related tables as shown in FIG. 2.Preferably, these tables include a table of events, a table ofobservations, a table of physical acts, and a table of speech acts. Aswill be described, the relational structure includes the pointers (keys)identified, and preferably look-ups in to the database are performed ona constant-time basis such that only a single database query into thedata structures is required for each database access (although there aretypically several of such accesses as will be described).

At a high level, the system 400 comprises several main components,namely, an event recognition sub-system 404, and an action selectionsub-system 406. The event recognition sub-system 404 has several basicfunctions. Initially, and upon receipt of a new user input, the eventrecognition sub-system 404 tries to decide how to interpret what wasactually said to the bot given what has been observed previously.Typically, an input can be successfully interpreted if two conditionsare met: (1) the user's input can be recognized as a speech act orphysical act that exists as an observation in the historical data, and(2) this observation can legally extend an event or start a new event,giving contextual meaning to the observation.

As noted above, event recognition is the process of first trying toextend an event, or adding a new event, or (failing those options)performing aliasing. In general, this evaluation is carried out using aninitial lookup into the database of historical transcripts to identifyone or more candidate interpretations, followed by a filtering of thecandidates for coherency (sometimes referred to herein as “coherencyfiltering”). More formally, a candidate interpretation typicallycorresponds to some human annotation found in the historicalconversation transcripts that were indexed during the packing operation.In one exemplary implementation, the candidate interpretation is apointer identifying specific lines of historical data in the set ofinter-related tables that comprise that relational database 402. Anotherway of describing a candidate interpretation is as an instance ofobservations, e.g., one candidate interpretation might be a specificutterance in a specific transcript that expresses the speech act “hello”with the line “hey man nice to see you.” Multiple candidateinterpretations are identified by a set of pointers to specific lines inthe transcripts, representing instances of observations.

Preferably, the input to event recognition sub-system 404, where thesystem tries to extend an event, etc., is represented as a sequence ofobservation identifiers (IDs), rather than instances. An ID is akin to atype of observation that may appear many times in the annotatedhistorical data, rather than one instance of an observation with thatID. To take a concrete example, assume the user utterance is “hello kindsir.” The classifier is run against the utterance, and in this examplethe classifier assigns the utterance the speech act label “hello.” Fromthis, the system looks up a speech act ID (for this label) from thespeech acts table. Then, from this speech act ID, the system looks up anassociated observation ID in the observations table. These lookupstypically are done at once, through SQL table joins. After determiningwhat observation ID “hello kind sir” maps to, the system tries to usethis observation ID to first extend an event. To this end, preferablythe data model is updated to reflect that the event is extended (at thispoint, merely an assumption that the event can be extended), and it isthe resulting modified event that the system then uses to perform theinitial lookup described above, namely, to fetch the one or morecandidate interpretations. These candidate interpretations are instancesof observations with the observation ID previously mentioned, e.g.,where the system found things like “hello.”

In addition to obtaining the one or more candidate interpretations, theevent recognition sub-system 404 evaluates the candidate interpretationsthat it fetches, with the goal of identifying one candidateinterpretation that it will then provide to update the data model beforethat updated model is then provided to the action selection sub-system406. In this initial pass, the event recognition sub-system 404functions to attempt to understand the user's input. A mechanism 408 forperforming this function preferably comprises a set of evaluation agentsthat are sometimes referred to herein as “critics.” Critics preferablyoperate over candidate interpretations. As used herein, a critictypically is a software agent (e.g., implemented as a Python class) thatevaluates a candidate interpretation against a statistical model, a setof hard-coded rules, or some other data or criteria, in each case todetermine whether the candidate interpretation should be used topotentially update the data model. Preferably, there are a plurality ofseparate and distinct “critics,” with each critic providing a particulartype of analysis, and a particular candidate interpretation must passeach and every critic. In other words, preferably the criticscollectively provide a Boolean AND function such that a candidateinterpretation is not accepted for use to update the data model unlessall critics are satisfied. Although this approach is preferred, theall-or-nothing criteria may be relaxed. The nature and processingperformed by a critic may vary from computationally-simple tasks (e.g.,evaluation of business logic), to more complex evaluation tasks (e.g.,evaluation against a statistical model). The critics may be arrangedsequentially, such that the more computationally-simple tasks are testedbefore the more complex ones. Critics may also operate in parallel withone another, and one or more critics may be combined into a singlecritic. In this manner, the critics selectively filter the candidateinterpretations so as to ensure that the bot operates coherently andconsistently given the conversation so far.

As noted above, event recognition tries to extend an event if it can doso. To this end, and as part of the event recognition function, thecritics are executed against the set of candidate interpretations. Ifthis initial pass through the critics returns a positive result, work ofthe event recognition sub-system is done (for this first pass), as thesub-system has recognized the user's input. If, however, the initialpass through the critics returns empty-handed (i.e., no candidateinterpretation survives), then the event recognition sub-system tries toassign a new event. The new event is a new instance of an event thatwill initially have only one observation in it, namely, a candidateinterpretation that makes it through the critics. To this end, a secondpass through the critics is performed. This second pass may or may notidentify a candidate interpretation. If a candidate interpretationpasses the critics, it is used for the new event. If, however,evaluation of the new event also returns empty-handed (i.e., nocandidate interpretation logically starts a new event), the routine thencontinues by moving on to event aliasing. As noted above, first thesystem tries an aliased event, where the system allows an aliasedaddition, namely, where a new instance of an event is started at aposition in the conversation where the system has not seen (in thehistorical data) that kind (label) of event start. Once again, thecritics are run again in an attempt to find a candidate interpretation.Processing efficiencies are provided by caching results of the criticevaluations where possible. The result of this iterative process (tryingfirst to extend an event, or start a new event, or aliasing an event,etc.) is a given candidate interpretation, and processing then continuesat the action selection sub-system 406.

To this end, the given candidate interpretation identified by the eventrecognition sub-system is applied to the data model to produce anadjusted data model. As used herein, adjusting the data model mayinvolve an addition to the data model, or not rolling back a change(which typically occurs when a candidate interpretation is rejected by acritic). The adjusted data model is then applied as an input to theaction selection sub-system 406, whose primary function is to proposewhat observations might come next. To this end, action selectionsub-system 406 tries different ways of navigating the transcript data tocome up with a set of one or more such observation(s) that mightlogically come next. An observation identified by the action selectionsub-system represents a component of an imagined future state of theconversation. Preferably, the action selection sub-system does notevaluate correctness (coherency) of the observation. Instead, and asdescribed below, action selection sub-system 406 hands the observations(in particular, their observation IDs) that it identifies back to theevent recognition sub-system 404, which then repeats its above-describedoperations(s) to evaluate correctness (coherence filtering). Thus, andaccording to this disclosure, the event recognition sub-system is usedto both understand the user, and to select a response to return to theuser.

The action selection sub-system 406 preferably operates as follows.Taking the adjusted (modified) data model as input, it performs anadditional database lookup pass through the historical transcripts inthe database 402, and in response generates a set of next possibleobservations. If these observations were to be applied to the datamodel, the resulting data model would represent one or more imaginedfuture states of the conversation. As such, this set of observationsrepresents possible responses that might be returned by the bot (as aresponse to the new user input). The action selection sub-system 406then iterates over different ways (strategies) to suggest whatobservation(s) could come next, and it returns a resulting set ofobservation IDs (corresponding to the identified observations) back tothe event recognition sub-system 404, thereby re-cycling them backthrough the coherency filtering process to test their coherency. Usingthe set of observation IDs proposed by the action selection sub-system,the event recognition sub-system 404 again tries to extend the event,etc., once again performing a query into the database for candidateinterpretations. The above-described processing by the event recognitionsub-system 404 is then repeated. In particular, the critics in the eventprocessing sub-system 404 are then run over the candidateinterpretations to find one single approved candidate (an instance). Atthis point the system has found a coherent response to the user input,the data model is adjusted to include it, and this response is thenselected to be returned.

Preferably, the action selection sub-system 406 includes a mechanism 410to identify the set of observations. Akin to the critics in the eventrecognition sub-system 404, the mechanism 410 comprises a set ofevaluation agents that are sometimes referred to as “action selectors.”As used herein, an action selector typically is a software agent (e.g.,once again implemented as a Python class) that provides a strategy fornavigating through the transcript data. Preferably, there are aplurality of separate and distinct “action selectors,” with each actionselector providing a particular strategy for navigating through thetranscript data. The nature and processing performed by an actionselector may vary from computationally-simple tasks, to more complexevaluation tasks. A simple action selector just tries whatever came nextin one particular log. A more complicated action selector tries to findways to complete events that are otherwise hanging open. Or, a selectormight try to urge the bot to start an event that will capture somevariable value that the bot knows it needs. These are just exampleaction selectors. As the action selection sub-system iterates over itsaction selectors, one or more observations (of what might come next) areidentified and sent back over to the event recognition sub-system, aspreviously noted. Once an action selector has found an observation thatis then approved via event recognition, the operation of the actionselection sub-system ends.

In operation, action selectors may be arranged sequentially, such thatthe more computationally-simple tasks are tested before the more complexones. Action selectors may also operate in parallel with one another,and one or more action selectors may be combined into a single actionselector. Preferably, as an action selector identifies a possibleobservation that could come next, it is returned to the eventrecognition sub-system for filtering, even as other action selectors arestill executing. In another embodiment, all of the action selections areenabled to complete their processing before the resulting one or moreobservations are returned (in effect, in batch) back for filtering

Critics and action selectors may be the same or distinct softwareagents. By way of example, the following agents apply to both eventrecognition and action selection:

CriticStaleExtension—after some number of conversational turns havepassed, it becomes unlikely that something someone just said is supposedto be interpreted as an extension of something said long ago in theconversation. This critic rejects an interpretation that tries to extendan event that has not changed in the recent several turns.

CriticExtendedEventTypeChange—sometimes extending an event with one moreobservation changes the label (and thus the meaning) of that event. Thesystem needs to be careful about allowing a semantic shift like this. Ifthe original event was not an alias, and changing the event label leavesit in a position in the conversation history where this ordering ofevents has not been observed, then the label change (via the eventextension) that would lead to this unfamiliar ordering of events is notallowed.

ActionSelectorContinueLog—this is the simplest action selector. Everytime critics approve a candidate interpretation, the system records inthe data model which line of which transcript that candidate pointed at.This action selector blindly proposes that the next thing to say iswhatever was said next in that particular transcript.

ActionSelectorCompleteEvent—this action selector detects that the datamodel contains one or more events that cannot yet be consideredcomplete—they still require extension with more observations before theyrepresent a whole instance of that event. This action selector proposesthe bot say (or do) something next that would be the next step inextending some existing event, to get it closer to completion. Forexample, if someone asked the bot “how are you today?”, that begins anevent that is not complete until the bot responds with “I'm well.”

ActionSelectorMotivation—this action selector encourages the bot to saysomething that prompts the user to answer with some missing piece ofqualifying information (e.g., in the context of qualifying sales leads).For example, the bot is aware that it still needs to know how manyemployees work for some company, so if the simpler action selectorsfail, it tries to move the conversation forward productively.

The following agents are only used during action selection:

CriticDuplicateUtternance—prevents the bot from saying the exact thingit has said previously within the same session;

CriticBizrule—prevents the bot from saying something that contradictssome piece of business logic. For example, this agent ensures that thebot does not say “sure, we will connect you to one of our sales repsright away!” if the system has already detected that this user's companyis in an industry or geographic location that is not being serviced.After the critic rejects this candidate bot response, it moves on toanother candidate that will get approved that might say “sorry, we don'toffer service in your location. Would you like to join our waiting listto be notified when coverage is extended?” or the like.

The above example agents are not intended to be limiting.

Utterance Ranking

As noted above, a common problem that occurs in an AI-based chatbotsolution such as described above occurs when a user (e.g., a customervisiting a website) says more than one statement at once to theconversational bot. A typical default operation is that the systemresponds to the most recent utterance for which a response action can bedetermined. Depending on context, however, this default behaviorsometimes is not correct, in which case the bot typically produces awrong (or context-inappropriate) response. FIG. 5 depicts an exampleconversation illustrating this problem. In this example, the botdefaults to respond to the last utterance when it should be respondingto the user's first utterance; here, too, the second utterance likewisecan be ignored. This is a common variety of the multi-utterance problem,in which the bot is responding to a most recent user utterance, eventhough the utterance itself is vacuous. FIG. 6 depicts a second examplewherein, although the last utterance in the group is not necessarilyvacuous, it is still not the most importance utterance to which the botshould respond. In this example, the bot response to the last (mostrecent) utterance is not classified correctly. Once again, here the mostimportant utterance is the first one in which the customer is asking totalk with a person. Both examples depict ways in which users interactwith bots and, in particular where the user is following up a requestwith a reason for the request. Other variants of multiple customerutterance sequences include multiple question sequences, multiplestatement sequences, and sequences with many more utterances. In all ofthese situations, it is desirable that the bot be able to recognize suchsequences of utterances and be able to appropriately determine whichutterance of the sequence should be addressed. This subject matterherein addresses this need.

According to a preferred approach, an utterance ranking algorithmgenerates a list of indexes that represent a ranking of simultaneous(concurrent) utterances by importance. In operation, the list generatedby the ranking algorithm is then passed to the component of the AIsystem that selects a next appropriate action (i.e., a response to aquery). As has been described, the action selector then steps throughthe history of the conversation according to the list to determine anapproved response action for one of the utterances.

The utterance ranking preferably takes into consideration a set offactors, which are now described. A primary factor is a “prioritystatus.” This is a special status that is provisioned for a (preferably)relatively small predetermined set of utterance classes that, based onthe implementation requirements, are flagged as priorities. When apriority (utterance) is observed in a sequence of customer utterances,the bot puts it at a top of an utterance ranking, regardless of whatother linguistic properties it may have. In one embodiment involving asales bot, the following types of utterances may be afforded prioritystatus: cross-domain priorities (e.g., demo_request, pricing_request,and person_request), domain-specific priorities (e.g.career_opportunity), and the like. Of course, the nature and type ofutterances that are afforded priority status will depend on theimplementation (the expected bot interactions).

A particular priority utterance class may have one or more associatedsub-rankings, with the sub-ranking then taking effect when there is morethan one priority uttered at once by a customer. Continuing with theabove examples, utterances classified at demo_request or pricing_requestare both ranked as more important than utterances classified asperson_request. To provide a more concrete example, consider twoutterances U1: “I want to schedule a demo” and U2: “Can I talk to aperson?” In these situations, it is safely assumed that the customer isrequesting a person to schedule a demonstration, and without knowledgeof whether the bot can do this task. An example ranking such asdemo_request>pricing_request tells the bot to respond to thedemonstration request, in which case it will get a demo scheduled, allwithout having to route the request to a person. Where utterances arenot likely to be made simultaneously, typically there is no need to do arelative ranking between them. Again, the nature of the sub-rankings andhow they are provisioned will be implementation-specific.

Another factor preferably considered by the algorithm distinguishes“statements” versus “non-statements.” In particular, whether or not acustomer utterance is a question/command (a “non-statement”) or astatement is factored into the rankings. Non-statements (questions andcommands) are ranked higher than statements. Preferably, questions andcommands are not ranked relative to each other, as they are not likelyto co-occur in the same sequence.

Another factor that is considered by the algorithm is “content value,”and this factor computes a quantitative measure of how much actualcontent is contained in an utterance. Preferably, and as will be seen,content value is measured and factored into the utterance ranking,typically with higher content utterances being ranked higher than lowercontent utterances. The content value for a particular utterance isdetermined by the content of the words that make up the utterance. Thefollowing describes one representative implementation of the contentscoring factor and, preferably, a content score is assigned to everyutterance in a sequence of customer utterances, including those thatfall into the prioritized utterance classes.

As noted, the content score of an utterance is determined by the contentvalue of the words in the utterance. A content value is a numericalweight assigned to a word. In one embodiment, there are multiple (e.g.,three or more) distinct word categories, with different “values” thenassociated with the different categories. For example, consider a schemawherein there are four (4) main categories of words corresponding totheir content values, namely, “zero-value” words, “low-value” words,“high-value” words, and “all other” words. In this example, “zero-value”words correspond to stop-words, high frequency, functional, vacuous oranaphoric words (e.g. “they,” “because,” “thanks” and others). As thename implies, these words are afforded a content value per word=0. Inthe next category, “low-value” words correspond to a set of words thatare not necessarily vacuous but should be treated as low-content givehow informative they are for what the bot cares about. Example words inthis category are “possible,” “great,” “helpful” and the like, and theyare afforded a content value per word=0.5. High-value words, incontrast, typically comprise a relatively small set of words thatindicate high content value in chats. In practice, these are words thatstrongly indicate requests that the bot should particularly care about,e.g., “demo,” “buy,” “integrate” and so forth, and they are afforded acontent value per word=3. In this example schema, the “all other” wordsclass is then a complement of the above three classes, with contentvalue per value=1. Of course, the above-identified classes, values, andassociated words are merely exemplary, as the scoring schema will varydepending on implementation. The content score for an utterance then isthe sum of the content values of each word in the utterance.

To provide a concrete example, a sentence such as “Would it be possiblefor you to do that for me, thanks?” has a word length=12 but a contentscore=0.5, as all of the words are non-zero, and the word “possible” isa low-value word. Another example, “Does Drift® integrate withSalesforce®? has a length=5 and a content score=5.0, as the word“integrate” is a high-value word, and the Company names are “all other”words. The first example then corresponds to a “low-content utterance,”namely, those with content score <1, whereas the second examplecorresponds to a “high-content utterance,” namely, those with contentscore 1. Of course, this breakpoint is also arbitrary, and the notion of“high-content” does not necessarily mean a high number for a contentscore, but only high relative to the low-content scores. This latterdistinction enables the algorithm to distinguish between utterance witha low content value and utterances with a high content value, regardlessof whether they are questions/commands or not. While questions andcommands (non-statements) are generally more important than statements,if a question/command has a content score less than, for example, 1, itis assumed to be too low in content to respond to unless there is nohigh-content alternative in the sequence.

As will be seen, preferably the priority utterances have priorityregardless of their linguistic properties, and the non-priorityutterances are evaluated for content and for non-statement status. Tothe end, the following describes a preferred algorithm for creatingutterance rankings.

In particular, FIG. 7 depicts a process flow that detects a sequence ofutterances that are to be prioritized for the bot. The routine begins atstep 700 given a list of utterances (or “observations”) representing thehistory of the conversation up to the current point-in-time (turn). Atstep 702, a backward search in this history is initiated until a botutterance is found. At step 704, if no customer utterance a test isperformed to determine if a bot utterance is found is found beforehitting a bot utterance (if the most recent utterance is from the bot),the routine waits for customer response. At step 706, if there is onlyone customer utterance found before finding a bot response, the routinereverts to a default behavior of responding to most recent customerutterance. At step 708, if a sequence of two or more customer utterancesis found, however, then the ranking algorithm is called.

FIG. 8 depicts a representative operation of the ranking algorithm.Preferably, the algorithm operates to construct a ranking of themultiple customer utterances found based on the three (3) types offactors described above. In general, the routine creates rankings withinsubclasses of utterances found in the sequence before joining thesub-rankings and rearranging the order to reflect all three factors.Stated another way, preferably the system ranks utterances in auser-input sequence by generating sub-rankings based on the threefactors of utterance meaning, utterance type and an utterance contentscore, and ordering these sub-ranking with respect to one another.

To this end, and assuming a sequence of unanswered customer utterancesis found in the conversational history (per the process flow in FIG. 7).The ranking algorithm begins at step 800 to extract the sequence ofunanswered utterances from the history and calculate a content score foreach utterance. At step 802, the routine separates this collection intoa set of four (4) buckets based on content scores and utterance type(question/commands vs. non-question): high-content questions/commands,low-content questions/commands, high-content non-question/commandslow-content non-questions/commands. At step 804, and within eachsub-group, the routine internally ranks the utterances based on theircontent scores. At step 806, the routine joints the lists created insteps 802 and 804, preferably in the following order: high-contentquestions/commands+high-content statements+low-contentquestions/commands+low-content statements. At step 808, the routineconducts a search of the list created in step 806 and, in particular,for utterances in a priority class. At step 810, the routine removes anysuch utterances (from a priority class) from the list created at step806 and adds them to a new list of priorities. If there is more than oneutterance in this new list of priorities, they are ordered with the mostrecent in the history being first. At step 812, the routine prepends thepriority list (the new list of priorities, possibly as re-ordered) tothe front of the list created in step 806 (with the priorities havingbeen previously removed. This results in a ranked list of the utterancesin the sequence, placing them into a ranked order of importance thatreflects a lowest to highest priority of response. At step 814, theranked list is passed to a component that then implements the rankingsin the bot's response to the customer.

In particular, FIG. 9 represents one embodiment that implements therankings provided by the ranking algorithm. In this embodiment, thesystem modifies the history that is tracked in the bot's data model toreflect the re-ranking. If there is a multi-utterance input from thehuman, the utterances are represented in the history order of lowest tohighest priority. To this end, at step 900 the ranking output from theranking algorithm is received. At step 902, the AI bot is then set torespond to the most recent utterance (the last utterance) in thehistory, which (based on the re-ranking provided by the algorithm) willalways be the most important given a sequence of utterances. Thisimplementation, wherein the bot responds to the most recent utterancefollowing the re-ranking of the utterances) avoids interfering with thebot's behavior in regards to event continuation, as described generallyabove. After the history is re-ordered, in the action selectioncomponent of the AI system, the bot considers the last utterance in theconversation history first and check for an approved action. At step904, and if an approved action is found, the bot performs the action. Atstep 906, and if an approved action is not found, the bot continuesstepping through the history backwards (i.e., through the utteranceranking) until an approved action is found for one of the utterances.

Although in a preferred embodiment, the re-ranking positions thehighest-ranked utterance as the most recent (so that the bot can processit preferentially), this is not a requirement. In an alternativeembodiment, the action selection component may receive the highestpriority utterance directly irrespective of its particular placement inthe data model.

In general, the process flows described above in FIGS. 7-9 areimplemented in software, as a set of computer program instructionsexecuted by one or more machines. The process flows may be integrated orexecuted as separate flows.

Illustrative examples of the operation of the ranking algorithm areprovided in FIGS. 10-12. These are representative but non-limitingsituations that would motivate the bot to respond to an utterance otherthan the most recent when facing a sequence of two or more customerutterances. FIG. 10 depicts multiple statement utterances. In Example 1,both utterances are non-priority statements and U1 is determined to bemore important because it has a content score of 6, where U2 has acontent score of 3. FIG. 11 depicts a mixture of questions andstatements. In Example 2, all utterances are non-priority. U1 and U3 arestatements and U2 is a question. U3 has a content value of 0 and isranked last. U2 is a question but is a low-content question (score of0.5), whereas U1 has a content value of 2.5 (with the word “something”being treated as a low content word with value 0.5) and is thus rankedhigher. In Example 3, both utterances are non-priority utterances and,while U2 has a higher content value than U1, U1 is determined to be moreimportant because it is a high-content question, whereas U2 is ahigh-content statement. FIG. 12 depicts multiple question utterances.Both utterances here are questions. U1 has a content score of 1 and U2 acontent score=2.5 but, because U1 is in the priority categorypricing_request, it is given a higher rank.

Variants

The bot may also be configured to determine when a subset of utterances(e.g., 2) in a set of multiple utterances are both worth responding to,in which case both are then responded to irrespective of the finalpriority determination. Example 4 in FIG. 12 is an example (here whereboth utterances should be given a response). This approach may be usedwhen there are multiple questions.

Another variant provides for more fine-grained content values, whichprovides that the utterance ranking may be more informed. For example,the fine-grained scoring may be configured to reflect the importance ofthe utterance(s) within the context of the conversational chat (or evenin a non-conversational chat), and not just relativeimportance/frequency in language use generally. When making morefine-grained scoring for words, importance need not be equated tolow-frequency (which is typical in NLP). Typically, the most importantwords for the bot will be frequent in comparison to othernon-stop-words.

Other implementation-specific ranking criteria may also be applied bythe algorithm.

Enabling Technologies

Typically, the computing platform is managed and operated “as-a-service”by a service provider entity. In one embodiment, the platform isaccessible over the publicly-routed Internet at a particular domain, orsub-domain. The platform is a securely-connected infrastructure(typically via SSL/TLS connections), and that infrastructure includesdata encrypted at rest, e.g., in an encrypted database, and in transit.The computing platform typically comprises a set of applicationsimplemented as network-accessible services. One or more applications(services) may be combined with one another. An application (service)may be implemented using a set of computing resources that areco-located or themselves distributed. Typically, an application isimplemented using one or more computing systems. The computing platform(or portions thereof) may be implemented in a dedicated environment, inan on-premises manner, as a cloud-based architecture, or some hybrid.

The system may be implemented on-premises (e.g., in an enterprisenetwork), in a cloud computing environment, or in a hybridinfrastructure. An individual end user typically accesses the systemusing a user application executing on a computing device (e.g., mobilephone, tablet, laptop or desktop computer, Internet-connected appliance,etc.). In a typical use case, a user application is a mobile application(app) that a user obtains from a publicly-available source, such as amobile application storefront. The platform may be managed and operatedby a service provider. Although typically the platform isnetwork-accessible, e.g., via the publicly-routed Internet, thecomputing system may be implemented in a standalone or on-premisesmanner. In addition, one or more of the identified components mayinteroperate with some other enterprise computing system or application.

Preferably, the platform supports a machine learning system. The natureand type of Machine Learning (ML) algorithms that are used to processthe query may vary. As is known, ML algorithms iteratively learn fromthe data, thus allowing the system to find hidden insights without beingexplicitly programmed where to look. ML tasks are typically classifiedinto various categories depending on the nature of the learning signalor feedback available to a learning system, namely supervised learning,unsupervised learning, and reinforcement learning. In supervisedlearning, the algorithm trains on labeled historic data and learnsgeneral rules that map input to output/target. The discovery ofrelationships between the input variables and the label/target variablein supervised learning is done with a training set, and the systemlearns from the training data. In this approach, a test set is used toevaluate whether the discovered relationships hold and the strength andutility of the predictive relationship is assessed by feeding the modelwith the input variables of the test data and comparing the labelpredicted by the model with the actual label of the data. The mostwidely used supervised learning algorithms are Support Vector Machines,linear regression, logistic regression, naive Bayes, and neuralnetworks. As will be described, the techniques herein preferablyleverage a network of neural networks. Formally, a NN is a function g:X→Y, where X is an input space, and Y is an output space representing acategorical set in a classification setting (or a real number in aregression setting). For a sample x that is an element of X, g(x)=f_(L)(f_(L−1)/( . . . ((f₁(x)))). Each f_(i) represents a layer, and f_(L) isthe last output layer. The last output layer creates a mapping from ahidden space to the output space (class labels) through a softmaxfunction that outputs a vector of real numbers in the range [0, 1] thatadd up to 1. The output of the softmax function is a probabilitydistribution of input x over C different possible output classes.

Thus, for example, in one embodiment, and without limitation, a neuralnetwork such as described is used to extract features from an utterance,with those extracted features then being used to train a Support VectorMachine (SVM).

In unsupervised machine learning, the algorithm trains on unlabeleddata. The goal of these algorithms is to explore the data and find somestructure within. The most widely used unsupervised learning algorithmsare Cluster Analysis and Market Basket Analysis. In reinforcementlearning, the algorithm learns through a feedback system. The algorithmtakes actions and receives feedback about the appropriateness of itsactions and based on the feedback, modifies the strategy and takesfurther actions that would maximize the expected reward over a givenamount of time.

The following provides additional details regarding supervised machinelearning. As noted above, supervised learning is the machine learningtask of inferring a function from labeled training data. The trainingdata consist of a set of training examples. In supervised learning,typically each example is a pair consisting of an input object(typically a vector), and a desired output value (also called thesupervisory signal). A supervised learning algorithm analyzes thetraining data and produces an inferred function, which can be used formapping new examples. An optimal scenario allows for the algorithm tocorrectly determine the class labels for unseen instances. This requiresthe learning algorithm to generalize reasonably from the training datato unseen situations.

For supervised learning, the following steps are used. An initialdetermination is what kind of data is to be used as a training set. Thetraining set is then gathered. In particular, a set of input objects isgathered and corresponding outputs are also gathered, either from humanexperts or from measurements. Then, an input feature representation ofthe learned function is determined. In this approach, typically theinput object is transformed into a feature vector, which contains anumber of features that are descriptive of the object. The structure ofthe learned function and corresponding learning algorithm are thendetermined. For example, support vector machines or decision trees maybe used. The learning algorithm is then run on the gathered trainingset. Some supervised learning algorithms require a user to determinecertain control parameters. These parameters may be adjusted byoptimizing performance on a subset (called a validation set) of thetraining set, or via cross-validation. The accuracy of the learnedfunction is then evaluated. After parameter adjustment and learning, theperformance of the resulting function is measured on a test set that isseparate from the training set.

One or more functions of the computing platform of this disclosure maybe implemented in a cloud-based architecture. As is well-known, cloudcomputing is a model of service delivery for enabling on-demand networkaccess to a shared pool of configurable computing resources (e.g.networks, network bandwidth, servers, processing, memory, storage,applications, virtual machines, and services) that can be rapidlyprovisioned and released with minimal management effort or interactionwith a provider of the service. Available services models that may beleveraged in whole or in part include: Software as a Service (SaaS) (theprovider's applications running on cloud infrastructure); Platform as aservice (PaaS) (the customer deploys applications that may be createdusing provider tools onto the cloud infrastructure); Infrastructure as aService (IaaS) (customer provisions its own processing, storage,networks and other computing resources and can deploy and run operatingsystems and applications).

The platform may comprise co-located hardware and software resources, orresources that are physically, logically, virtually and/orgeographically distinct. Communication networks used to communicate toand from the platform services may be packet-based, non-packet based,and secure or non-secure, or some combination thereof.

More generally, the techniques described herein are provided using a setof one or more computing-related entities (systems, machines, processes,programs, libraries, functions, or the like) that together facilitate orprovide the described functionality described above. In a typicalimplementation, a representative machine on which the software executescomprises commodity hardware, an operating system, an applicationruntime environment, and a set of applications or processes andassociated data, that provide the functionality of a given system orsubsystem. As described, the functionality may be implemented in astandalone machine, or across a distributed set of machines.

Other enabling technologies for the machine learning algorithms include,without limitation, vector autoregressive modeling (e.g., AutoregressiveIntegrated Moving Average (ARIMA)), state space modeling (e.g., using aKalman filter), a Hidden Markov Model (HMM), recurrent neural network(RNN) modeling, RNN with long short-term memory (LSTM), Random Forests,Generalized Linear Models, Extreme Gradient Boosting, Extreme RandomTrees, and others. By applying these modeling techniques, new types offeatures are extracted, e.g., as follows: model parameters (e.g.coefficients for dynamics, noise variance, etc.), latent states, andpredicted values for a next couple of observation periods.

Typically, but without limitation, a client device is a mobile device,such as a smartphone, tablet, or wearable computing device, laptop ordesktop. A typical mobile device comprises a CPU (central processingunit), computer memory, such as RAM, and a drive. The device softwareincludes an operating system (e.g., Google® Android™, or the like), andgeneric support applications and utilities. The device may also includea graphics processing unit (GPU). The mobile device also includes atouch-sensing device or interface configured to receive input from auser's touch and to send this information to processor. Thetouch-sensing device typically is a touch screen. The mobile devicecomprises suitable programming to facilitate gesture-based control, in amanner that is known in the art.

Generalizing, the mobile device is any wireless client device, e.g., acellphone, pager, a personal digital assistant (PDA, e.g., with GPRSNIC), a mobile computer with a smartphone client, or the like. Othermobile devices in which the technique may be practiced include anyaccess protocol-enabled device (e.g., an Android™-based device, or thelike) that is capable of sending and receiving data in a wireless mannerusing a wireless protocol. Typical wireless protocols are: WiFi,GSM/GPRS, CDMA or WiMax. These protocols implement the ISO/OSI Physicaland Data Link layers (Layers 1 & 2) upon which a traditional networkingstack is built, complete with IP, TCP, SSL/TLS and HTTP.

Each above-described process preferably is implemented in computersoftware as a set of program instructions executable in one or moreprocessors, as a special-purpose machine.

While the above describes a particular order of operations performed bycertain embodiments of the invention, it should be understood that suchorder is exemplary, as alternative embodiments may perform theoperations in a different order, combine certain operations, overlapcertain operations, or the like. References in the specification to agiven embodiment indicate that the embodiment described may include aparticular feature, structure, or characteristic, but every embodimentmay not necessarily include the particular feature, structure, orcharacteristic.

While the disclosed subject matter has been described in the context ofa method or process, the subject matter also relates to apparatus forperforming the operations herein. This apparatus may be a particularmachine that is specially constructed for the required purposes, or itmay comprise a computer otherwise selectively activated or reconfiguredby a computer program stored in the computer. Such a computer programmay be stored in a computer readable storage medium, such as, but is notlimited to, any type of disk including an optical disk, a CD-ROM, and amagnetic-optical disk, a read-only memory (ROM), a random access memory(RAM), a magnetic or optical card, or any type of media suitable forstoring electronic instructions, and each coupled to a computer systembus.

A given implementation of the computing platform is software thatexecutes on a hardware platform running an operating system such asLinux. A machine implementing the techniques herein comprises a hardwareprocessor, and non-transitory computer memory holding computer programinstructions that are executed by the processor to perform theabove-described methods.

The functionality may be implemented with other application layerprotocols besides HTTP/HTTPS, or any other protocol having similaroperating characteristics.

There is no limitation on the type of computing entity that mayimplement the client-side or server-side of the connection. Anycomputing entity (system, machine, device, program, process, utility, orthe like) may act as the client or the server.

While given components of the system have been described separately, oneof ordinary skill will appreciate that some of the functions may becombined or shared in given instructions, program sequences, codeportions, and the like. Any application or functionality describedherein may be implemented as native code, by providing hooks intoanother application, by facilitating use of the mechanism as a plug-in,by linking to the mechanism, and the like.

The platform functionality may be co-located or various parts/componentsmay be separately and run as distinct functions, perhaps in one or morelocations (over a distributed network).

Each above-described process preferably is implemented in computersoftware as a set of program instructions executable in one or moreprocessors, as a special-purpose machine.

The techniques herein generally provide for the above-describedimprovements to a technology or technical field, as well as the specifictechnological improvements to various fields, all as described above.

The above-described solution may be implemented across various usecases. A representative (but non-limiting) use case is a chatbot that isused as an alternative to a human Sales Development Representative (SDR)to help an organization scale to handle a larger volume of traffic thata sales team can support, and to handle conversations at off-hours orotherwise when no humans are standing by or available.

Although the above-described workflow is described in the context of achat, this is not a limitation. Generalizing, the multi-turnconversation is one of: chat, e-mail, SMS and a voice-based interaction.

What is claimed is as follows:
 1. A method for imitating a humanconversational response using a set of conversations that have beenannotated to identify speech acts, and physical acts, wherein a speechact is a labeled grouping of utterances, comprising: in association withan automated conversational bot executing in a computing system:receiving a data model associated with a multi-turn conversation, thedata model comprising an observation history; upon receipt of a querythat includes a sequence of utterances, applying an utterance rankingalgorithm that outputs a ranked order of importance of the utterances inthe sequence, the ranked order of importance reflecting a lowest tohighest priority of response, and wherein a position of a givenutterance in the ranked order of importance also reflects an importanceof the given utterance within a context of the multi-turn conversation;in response to applying the utterance ranking algorithm, updating thedata model to reflect the ranked order; and using the updated data modelto attempt to generate a coherent response to the query for theautomated conversational bot; and the automated conversational botreturning the coherent response to the query.
 2. The method as describedin claim 1 wherein updating the data model positions a highest priorityutterance as a most recent utterance in the observation history.
 3. Themethod as described in claim 2 wherein using the data model to attemptto generate a coherent response searches for a correct action to a nexthighest priority utterance when a response to the highest priorityutterance cannot be found.
 4. The method as described in claim 1 whereinthe given utterance is an utterance that has a low frequency of languageuse.